D3 Claims

Problem statement

A smart router needs to intelligently detect and take meaningful mitigating action to protect against security threats. To achieve this at scale we need an interoperable language to describe events, devices and, importantly, device types. An ability to meaningfully and interoperability describe device types is critical for both:

• collaborations: linking up different databases and systems.
• intelligence: intelligent action depends on the ability to reason about the generic, not just the specific.

The creation of the device vocabulary is a distributed problem; the device manufacturer is not always the best source of truth.

The Many Secured system will support:

1. Claims about device types and device type qualities to be made by different stakeholders.
2. Claims about real-time events.
3. An ability to express and interrogate who claimed what - a composable identity, supporting at a minimum individual identity and organisational identity (e.g. current employer).
4. A flexible method of making inferences about claims, where the inference engine (D3 agent) can have its own trust policy.

D3 foundations

Every D3 statement is an issued verified credential.

We will break down D3 statements into two types:

• Assertions: these are statements of fact, where the evidence of this fact comes from an external system.
• Inference: these are new D3 statements that can be logically inferred from other D3 statements that have been asserted or inferred (hence recursive).

Each claim has provenance. Technically, the issuer of the claim is the signatory.

Each claim has a subject, the primary entity to which the claim refers.

D3 standard attributes

Each D3 claim will have the following properties:

• id: (optional) used to refer to the claim, typically a URI
• type: (required) information related to the type of credential this is
• credentialSubject: (required) the entity about which a claim is being made, for our purposes this is the payload of the claim
• issuanceDate: (optional) date on which it was issued (ISO compliant time string)
• issuer: (optional) entity making the claim
• proof: (optional) typically provided by the issuer as a method to verify the claim is genuine

The credentialSubject will encapsulate the payload of the claim i.e. the data associated with the claim type.

D3 Inferences

Within the D3 system there are three forms of inference:

• Deductive inferences: where use general statements to infer facts about specific instances. In D3 this is typically where we ascribe a fact/assertion to a device instances, by virtue of the fact that we know this device instance to be a certain type. In other words a device instance inherits properties from its type.
• Inductive inferences: where use a collection of statements about specific instances to infer facts about the generalised type. This is a statistical or learning process, that typically requires a threshold of confidence before we can enact. In D3 this is typically where we try to infer properties about a general device type, form the observed behaviour of instances of that type. An inductive inference is never certain; it is based a form of statistical or probabilistic analysis.
• Algorithmic inferences: we use the term algorithmic inference, as a catchall for any generic process that is capable of creating a new claim based upon the evidence presented

D3 Clients and Projections

A D3 client is a entity that has access to D3 streams of information.

The client may also have access to pools (databases) of information, but each D3 pool is essentially a stream, in that each D3 statements can be replayed in issuanceDate order.

In order to reason about the current state of a system, the D3 client can create a projection against the D3 streams.

A D3 projection has certain essential properties

• Time variant: a D3 stream represents changing facts over time. Hence a projection is dynamic, and can represent facts about a changing world
• Conflict resolution: D3 streams may contain conflicting statements about subjects. The projection algorithm may implement strategies to resolve these conflicts
• Subjective trust framework: each projection may have different trust anchors: the extent to which this client trusts statements from different sources (issuers).

The specification and implementation of the projection method is out of scope

D3Events and D3

D3Events events are essentially compact D3 events streamed and stored.

The for efficiency reasons we just assume all D3Events data to be signed by the capturing network router.

DCon and D3

DCon commands are currently gRPC services. We could consider encapsulating each DCon command as a VC statement which represents an "intent".

These VC encapsulated DCon command could be passed to the audience.

This would be a good way of implementing high latency (fire and forget) functional interfaces.

Notation Conventions

To illustrate the D3 statements we will use YAML representations of D3 statements. All attributes are written in camel case.

By using YAML it is easier to incorporate comments into the examples and it makes the representations easy to read.

Each credential, will have the following standard VC attributes:

• type: a d3 scope string which identifies the statement type
• credentialSubject: the princple payload/content of the credential
• issuer (optional): some d3 claims will qualify the issuer or issuer type. Where this is not specified, the issuer is implicitly the D3 open source community

Each statement will have its own ID, which is simply a fresh GUID/UUID.

Entity types (Issuers)

The D3 claims will include the following minimal types:

A PERSON is an individual. They will be frequently be identified by email. For example joe.bloggs@internetprovider.com or joe.bloggs@employee.com. Possibly non email identifiers could be used (e.g. DID). The person may provide a personal identifier or an identifier provided by their employee (different emails examples). A PERSON may make CLAIMS

AGENT is functioning software. The AGENT might run locally (on an edge gateway or a mobile device) can also make claims, as determined by some internal logic.

CLOUD is also a form of agent, but sits on the internet (rather then the intranet). CLOUD agents are useably referable using REST interfaces

CODE can also make claims, as determined by some internal logic.

An ORG is a legal entity. For the purposes of claims, the ORG will usually be referenced by is primary internet domain e.g. www.exmaple.com.

All of these entity can issue claims (make statements) about other entities

Entity types (Referred to)

Other types of entity that can be referred to, but not necessarily issue claims.

Device INSTANCE is an specific physical individual device attached to the network. And for the ManySecured scenario, this is typically the internal intranet.

Device TYPE is an abstract type of device. Classically comprising a model number and manufacturer.

Identity options

For an entity to be referenced by a claim, it needs a stable identity.

These identities can come in several forms. These are listed below:

• Arbitrary string: no strong assurance of stability
  • GUID/UUID (preferred) - special case of arbitrary string with reasonable assurance of uniqueness
• Unique URI: ideally persistent
• Public Key - allocated to the device
• DID (https://www.w3.org/TR/did-core/) essentially a combo of the above to – stable links to the keys to facilitate rotation

The last two methods provide ability of entities to make statements about other entities.

Each individual claim will have an identity. This identity will be a GUID/UUID by default.